[browser][mono] Resolve LibraryImport via dlopen/dlsym for WASM side modules (#123570)#123571
[browser][mono] Resolve LibraryImport via dlopen/dlsym for WASM side modules (#123570)#123571denis-kudelin wants to merge 2 commits intodotnet:mainfrom
Conversation
601c1c7 to
3792bbc
Compare
@dotnet-policy-service agree |
3792bbc to
5b3df3e
Compare
1d85720 to
c1e7b21
Compare
19653bc to
05d685a
Compare
05d685a to
c786360
Compare
c786360 to
381c38e
Compare
…t#123570) Signed-off-by: Denis Kudelin <15978569+denis-kudelin@users.noreply.github.com>
381c38e to
7174b67
Compare
| @@ -254,7 +254,17 @@ wasm_dl_load (const char *name, int flags, char **err, void *user_data) | |||
| return sysglobal_native_handle; | |||
|
|
|||
| #if WASM_SUPPORTS_DLOPEN | |||
There was a problem hiding this comment.
I guess WASM_SUPPORTS_DLOPEN was never set outside of Zoltan's machine few years back when he established WASM as a target.
@lewing let's discuss if we want to make emscripten -sMAIN_MODULE=1 supported mode.
One of the use-cases I know about is godotengine
There was a problem hiding this comment.
We would have to make it work also for CoreCLR flavor.
runtime/src/native/corehost/browserhost/browserhost.cpp
Lines 102 to 107 in 5e389de
There was a problem hiding this comment.
I guess
WASM_SUPPORTS_DLOPENwas never set outside of Zoltan's machine few years back when he established WASM as a target.@lewing let's discuss if we want to make emscripten
-sMAIN_MODULE=1supported mode. One of the use-cases I know about is godotengine
I’ve already enabled -s MAIN_MODULE=1 (also -s MAIN_MODULE=2) in my "product", but I’ll need to ship it together with a custom prebuilt runtime built with additional flags. I’m currently testing to make sure everything works.
I intend to use this “open door” to build NativeAOT WASM using my own SDK (https://github.com/Itexoft/default-sdks/tree/master/src/NET.Sdk), which is still in progress.
I’ll mark the PR as "Ready" once I verify everything.
There was a problem hiding this comment.
Right, -sMAIN_MODULE=2 is better than -sMAIN_MODULE=1
I would like to see how emscripten implements the cross-module call dispatch. I'm interested to understand the performance overhead of that. For that I would appreciate if you can host small demo site somewhere. Ideally Debug build with all symbols.
Also I wonder what are the other impacts of -sMAIN_MODULE=1/2 onto the runtime.
- I guess multi-threading would not work at all ?
- are non-emscripten native functions propagated by emscripten at compile time ? Do you in fact you need whole-app linking anyway ?
- what other impacts do you observe (as compared to linking all into one native module)
- Is there some mapping table in the emscripten internals ? Or is that just WebAssembly.Table ?
Many thanks!
There was a problem hiding this comment.
Right,
-sMAIN_MODULE=2is better than-sMAIN_MODULE=1I would like to see how emscripten implements the cross-module call dispatch. I'm interested to understand the performance overhead of that. For that I would appreciate if you can host small demo site somewhere. Ideally Debug build with all symbols.
Also I wonder what are the other impacts of
-sMAIN_MODULE=1/2onto the runtime.
- I guess multi-threading would not work at all ?
- are non-emscripten native functions propagated by emscripten at compile time ? Do you in fact you need whole-app linking anyway ?
- what other impacts do you observe (as compared to linking all into one native module)
- Is there some mapping table in the emscripten internals ? Or is that just WebAssembly.Table ?
Many thanks!
|
Reopened #123634, deleted the branch by accident. |
Fixes #123570
Summary
Enable LibraryImport to resolve symbols from Emscripten side modules by falling back to dlopen/dlsym after the pinvoke table check, and surface meaningful managed errors on failure.
Motivation
In browser-wasm with MAIN_MODULE/SIDE_MODULE, LibraryImport names are not in the generated pinvoke table. Without a dlopen/dlsym fallback, side modules cannot be resolved even when present.
Changes